home *** CD-ROM | disk | FTP | other *** search
/ Software Vault: The Diamond Collection / The Diamond Collection (Software Vault)(Digital Impact).ISO / cdr16 / tc14_441.zip / TC14-441.TXT < prev    next >
Text File  |  1995-01-22  |  23KB  |  602 lines

  1. TELECOM Digest     Tue, 6 Dec 94 14:23:00 CST    Volume 14 : Issue 441
  2.  
  3. Inside This Issue:                          Editor: Patrick A. Townson
  4.  
  5.     Internet (was Re: MCI's Announcement) (Ajay Shah)
  6.     Re: Pager Advice Wanted (Andrew Laurence)
  7.     Call For Papers: ICCC95 (Lee JaiYong)
  8.     Re: Emergency Numbers in Various Countries (Yves Blondeel)
  9.     Re: WilTel Ignores *67 For Caller ID, Also Incorrect Billing (Glen
  10. Roberts)
  11.     Re: 911 From Unactivated Cell Phone? (Shawn Gordhamer)
  12.  
  13. TELECOM Digest is an electronic journal devoted mostly but not
  14. exclusively to telecommunications topics. It is circulated anywhere
  15. there is email, in addition to various telecom forums on a variety of
  16. public service systems and networks including Compuserve and America
  17. On Line. It is also gatewayed to Usenet where it appears as the 
  18. moderated
  19. newsgroup 'comp.dcom.telecom'. 
  20.  
  21. Subscriptions are available at no charge to qualified organizations
  22. and individual readers. Write and tell us how you qualify:
  23.  
  24.                  * telecom-request@eecs.nwu.edu *
  25.  
  26. The Digest is edited, published and compilation-copyrighted by Patrick
  27. Townson of Skokie, Illinois USA. You can reach us by postal mail, fax 
  28. or phone at:
  29.                     9457-D Niles Center Road
  30.                      Skokie, IL USA   60076
  31.                        Phone: 708-329-0571
  32.                         Fax: 708-329-0572
  33.   ** Article submission address only: telecom@eecs.nwu.edu **
  34.  
  35. Our archives are located at lcs.mit.edu and are available by using
  36. anonymous ftp. The archives can also be accessed using our email
  37. information service. For a copy of a helpful file explaining how to
  38. use the information service, just ask.
  39.  
  40. **********************************************************************
  41. ***
  42. *   TELECOM Digest is partially funded by a grant from the              
  43. *
  44. * International Telecommunication Union (ITU) in Geneva, Switzerland    
  45. * under the aegis of its Telecom Information Exchange Services (TIES)   
  46. * project.  Views expressed herein should not be construed as 
  47. represent-*
  48. * ing views of the ITU.                                                 
  49. *
  50. **********************************************************************
  51. ***
  52.  
  53. Additionally, the Digest is funded by gifts from generous readers such
  54. as yourself who provide funding in amounts deemed appropriate. Your 
  55. help 
  56. is important and appreciated.
  57.  
  58. All opinions expressed herein are deemed to be those of the author. 
  59. Any
  60. organizations listed are for identification purposes only and messages
  61. should not be considered any official expression by the organization.
  62. ----------------------------------------------------------------------
  63.  
  64. Date: Tue, 6 Dec 94 14:40:53+050
  65. From: ajayshah@cmie.ernet.in (Ajay Shah)
  66. Subject: Internet (Was Re: MCI's Announcement)
  67.  
  68.  
  69. I don't think it's so bad.
  70.  
  71. John Higdon <john@bovine.ati.com> writes:
  72.  
  73. > The Internet has several, distinctive traditions. One is the concept
  74. > of, as you put it, fixed rate access. Need to download a couple of
  75. > megabytes of material? Fine. How fast the transfer takes place is
  76.  
  77. Fixed rate access is also music to the ears of _paying_ customers.
  78. Look at the success of netcom, for example.  Internet providers that
  79. meter by the hour are going to find life very difficult.
  80.  
  81. So I don't see how the likes of MCI can dislodge fixed rate access.
  82.  
  83. > The commercializers would like to begin charging you for each and
  84. > every item you download or utilize. As carriers, they would do this 
  85. by
  86.  
  87. This is technically infeasible if a Internet provider is giving out IP
  88. connectivity.  If lusers are stupid enough to buy some shrink wrapped
  89. web browser running under MSW, which might support some ridiculous
  90. metering-per-use concepts, then it's their funeral.  Internet
  91. providers who sell such applications won't be hurting "our Internet".
  92.  
  93. > But what is more sinister involves a redefinition of the Internet
  94. > structure from peer-to-peer to client/server. The commercializers 
  95. see
  96.  
  97. That is not really true.  The basic protocols, and their symmetry
  98. between peers, are very much in place.  The only new twist is idiocy
  99. like shrink-wrapped MS Windows applications which let you access the
  100. net without knowing anything.
  101.  
  102. > make money is with such a device. If it is necessary to kill the
  103. > Internet in order to save it by turning it into a gigantic Prodigy 
  104. or
  105. > CompuServe, then the era is at an end. The great Information
  106. > Superhighway that we have been looking forward to will be nothing 
  107. more
  108. > than 500 cable channels and a dozen shopping channels.
  109.  
  110. >> it. My main concern is that those of us who have over the years 
  111. helped
  112. >> to make the net what it is today not be forgotten.   PAT]
  113.  
  114. I have some slightly heretical opinions on this:
  115.  
  116. a) I think VOD is much oversold.
  117.  
  118.    It takes T1 lines to the home to deliver VOD, and that is some 
  119.    ways off.
  120.  
  121.    The new medium that is the Internet is capable of a whole
  122.    lot of wonderful things; it is not clear that a server offering
  123.    a "family ties" episode of your choice is the smartest thing that
  124.    we can do (in a money-maximising sense) with something like the
  125.    Internet.
  126.  
  127.    Instead the "killer app" is likely to be applications like the web,
  128.    which work _now_ off 14.4k lines.  I think multi user games have
  129.    a great future.  When you can play multi user games, I think you
  130.    won't want to see conventional hollywood programming.  In that
  131.    sense I think the threat of the internet turning into cableTV-
  132.    just-VOD is overrated.
  133.  
  134. b) I think the greatest threat is the creeping encroachment
  135.    of Microsoft into internet protocols.  Microsoft is trying
  136.    to basically ignore the RFC procedure in connection with
  137.    internet protocols, and I think that is terribly dangerous.
  138.  
  139.    Similarly, at a technical level, if protocols like SMTP and HTTP
  140.    evolve in the direction of a commercial internet, then that will be
  141.    quite sad.  There is a message for us: if you care about this,
  142.    then participate in standards processes!  Otherwise we'll have
  143.    gunk like Microsoft breathing down our necks.
  144.  
  145. c) Another threat is the swamping of the original Internet crowd
  146.    by the great unwashed masses.  I'm quite elitist, and I think 
  147.    that  an internet built of people from the great universities 
  148.    and research institutions was a Good thing.  But exactly how 
  149.    will this swamping occur? Anyway we're not going to have these
  150.    newbies participating in things like comp.dcom.telecom
  151.  
  152.    Answer: we're going to have them on groups like alt.sex!  :-)
  153.    Conclusion: the great unwashed masses will "spoil" some 
  154. recreational
  155.    parts of the net for us.  But the more fascinating recreational
  156.    parts, like comp.unix.wizards, are unlikely to be hurt.
  157.  
  158. I full well expect the origins of the Internet will be shrouded in
  159. mystery and mostly forgotten by "the masses".  How many people using
  160. PCs know about the noble origins of MS-DOS?  :-) There will always be
  161. a hacker community which will have a different view of the world, but
  162. that community will increasingly become a tiny minority on the net.  I
  163. guess that's okay.
  164.  
  165.  
  166. ans
  167.  
  168. ------------------------------
  169.  
  170. From: laurence@netcom.com (Andrew Laurence)
  171. Subject: Re: Pager Advice Wanted
  172. Organization: NETCOM On-line Communication Services (408 261-4700 
  173. guest)
  174. Date: Tue, 6 Dec 1994 00:38:26 GMT
  175.  
  176.  
  177. brunelle@u.washington.edu (Russell Brunelle) writes:
  178.  
  179. > It would have to have a monthly fee that's very low (I don't mind if
  180. > the unit is expensive to buy, because I'm paying for that, but she
  181. > will be paying the monthly fee so that should be QUITE low), a 
  182. display
  183. > that can light up so you can read it when it's dark, the ability to
  184. > vibrate (or do something quietly) instead of beep so it doesn't bug
  185. > people, and the ability to store a few numbers in case several 
  186. people
  187. > call in a row.
  188.  
  189. I pay $8.50 per month for unlimited use on a six-month contract. I
  190. live in the San Francisco Bay Area. I bought a used Motorola Bravo
  191. numeric only display pager for $25 from someone on the Net, and it's
  192. worked fine.  I broke the belt clip, replaced it, and later broke the
  193. flange where the clip fits into the pager housing, so I bought a new
  194. housing for $10, and now I have a cool-looking magenta translucent
  195. housing (you can see the "guts").
  196.  
  197. > I would also like (and perhaps here is where some advice would come
  198. > in) the ability to send some sort of message with the phone number.
  199. > This could be as simple as the pager allowing me to type more than
  200. > seven digits so the first seven digits would be the phone number she
  201. > should call and the rest are a code indicating generally what the 
  202. call
  203. > is about and how urgent it is (i.e. 44 for it's just to chat, 77 for
  204. > the cat died, etc.).  Is there some way to type a space or dash
  205. > character so the person can tell where the phone number ends and the
  206. > code begins?
  207.  
  208. Pressing the * key on a touch-tone phone will generate a hyphen on
  209. most pagers. It certainly works on mine. My carrier is PageNet, and I
  210. believe they have an office in the Seattle area.
  211.  
  212. > Also, wasn't there a book published recently with three digit codes
  213. > for various messages?  Does anyone know what this was called or 
  214. where
  215. > I could find something like this?
  216.  
  217. I am not aware of this, but it sounds like a good idea.
  218.  
  219. > What sort of pager should I get, and where could I get it the most
  220. > inexpensively?  Is there some neat new feature I should look for in 
  221. a
  222. > pager?
  223.  
  224. Motorola Bravo, Bravo Plus, and Bravo Express tend to be reliable and
  225. easily affordable. Some resellers offer a pager cheap if you sign up
  226. for service. Also, you can usually buy a pager and apply for service
  227. at Price Costco warehouses.
  228.  
  229.  
  230. Andrew Laurence laurence@netcom.com | | Certified NetWare
  231. Administrator (CNA) Oakland, California, USA | | CD-ROM Networking
  232. Consultant Pacific Standard Time (GMT-8) | | Phone: (510) 547-6647
  233. Pager: (510) 308-1903 Fax: (510) 547-8002 
  234.  
  235. ------------------------------
  236.  
  237. From: jyl@yiscgw.yonsei.ac.kr (Lee JaiYong)
  238. Subject: Call For Papers: ICCC95
  239. Date: 6 Dec 1994 11:52:17 GMT
  240. Organization: Yonsei University
  241.  
  242.  
  243. Following is the SECOND CALL FOR PAPER for ICCC'95(revised version) to
  244. be held in Seoul Korea 1995.
  245.  
  246. Publicity Chair, 
  247. ICCC'95
  248.          ----------cut here-----------
  249.  
  250.                         CALL FOR PAPERS
  251.                              ICCC '95 
  252.  
  253.        "Information Highways for a Smaller World  & Better Living" 
  254.      Seoul, Korea
  255.                      August 21 - 24, 1995
  256.  
  257.  
  258.     The ICCC, the International Council for Computer Communication 
  259. (ICCC), 
  260.     founded in 1972,  is an Affiliate Member of the International 
  261. Federation 
  262.     for Information Processing (IFIP). 
  263.  
  264.     Its purposes are to foster:   
  265.        scientific research and the development of computer 
  266. communication;
  267.         progress in the evaluation of applications of computer 
  268. communication 
  269.  to educational, scientific, medical, economic, legal, cultural and 
  270.  other peaceful purposes;
  271.         study of the potential social and economic impacts of computer 
  272.  communcation and of policies which influence those impacts. 
  273.  
  274.     This 12th conference aims at providing a forum to exchange ideas, 
  275. discuss 
  276.     key issues and to present  the late research results for 
  277. "Information 
  278.     Highways for a Smaller World & Better Living."  The main program 
  279. includes
  280.     technical presentations, invited talks, tutorials, and technical 
  281. visits. 
  282.  
  283.     TOPICS :  Areas of interest include but are not limited to
  284.  
  285.  . Strategies, Policies, and User       . Wireless Communications
  286.    Perspectives of Information          . Intelligent Networks
  287.    Superhighways                        . Personal Communication 
  288. Systems
  289.         . Social and Economical Impacts        . Broadband 
  290. Communication
  291.    of Information Superhighways         . ATM Switching
  292.         . Computer Communication for           . International 
  293. Emergencies
  294.    Developing Countries                 . Distance Learning
  295.         . Network Planning                     . Optical 
  296. Communications
  297.  . Security and Privacy in Computer     . Multimedia Communication and 
  298.           Communications                         its Applications 
  299.         . Evolution towards the High-Speed     . High-Speed Protocols
  300.    Networks including Frame Relay       . Network Management  
  301.    and SMDS                             . Protocol Engineering     
  302.  . Packet Radio Technologies
  303.  . Satellite Communications
  304.  
  305.  
  306.     SUBMISSION OF PAPERS  
  307.  
  308.         Prospective authors should send 5 copies of a full paper to
  309. the following address:
  310.  
  311.   ICCC'95
  312.   Dr. Seon Jong Chung
  313.   ICCC'95 Technical Program Chairman
  314.   ETRI,  Yusong P.O.Box 106, Taejon, Korea, 305-606
  315.   Tel: +82-42-860-8630
  316.   Fax: +82-42-860-6465
  317.   E-mail: iccc95@giant.etri.re.kr
  318.  
  319. The manuscript should not exceed 4000 words in length and should
  320. include author's name, affiliation, and addresses(telephone, e-mail,
  321. fax), and 150-200 words abstracts in the title page. Also, authors are
  322. encouraged to send a Postscript version of their full paper to the
  323. Technical Program Committee Chairman by e-mail iccc95@giant.etri.re.kr
  324.  
  325.                      |-------------------------------|
  326.                      |  Important Dates              |
  327.                      |    Submission of Paper        |
  328.                      |      February 1st, 1995       |
  329.                      |    Notification of Acceptance |
  330.                      |      May 1st, 1995            |
  331.                      |    Camera-ready Papers        |
  332.                      |      June 15th, 1995          |
  333.                      |-------------------------------|
  334.     Sponsored by
  335.  The International Council for Computer Communication
  336.  
  337.     Hosted by
  338.  Electronics and Telecommunications Research Institute
  339.  Korea Information Science Society
  340.  
  341.     Under the Patronage of
  342.  Ministry of Communication, The Republic of Korea
  343.  
  344.     Conference Governor                          
  345.  Ronald P.Uhlig, Northern Telecom, U.S.A.
  346.  
  347.     Conference Organizing Committee
  348.  Chair : Chongsun Hwang, KISS, Korea
  349.  Co-Chair : Seungtaik Yang, ETRI, Korea
  350.  
  351.     Local Arrangement 
  352.  Dongho Lee, Kwangwoon Unvi., Korea
  353.  
  354.     Publication 
  355.  Keosang Lee, Dacom, Korea
  356.     
  357.     Publicity
  358.  Jaiyong Lee, Yon-Sei Univ., Korea
  359.  
  360.     Registration 
  361.  Samyoung Suh, NCA, Korea
  362.  
  363.     Treasurer 
  364.  Seungkyu Park, Ajou Univ., Korea
  365.  
  366.     Tutorial 
  367.  Sunshin An, Korea Univ., Korea
  368.  
  369.     Social Program 
  370.  Nosik Kim, KTRC, Korea
  371.  
  372.     Secretariate 
  373.  Yanghee Choi, SNU, Korea
  374.         Jinpyo Hong, ETRI, Korea
  375.  
  376.     Technical Program 
  377.         Chair : Seonjong Chung, ETRI, Korea
  378.  Co-Chairs : Serge Fdida, MASI, France
  379.       Nicholas Georganas, Univ. of Ottawa, Canada
  380.       Roger Needham, Univ. of Cambridge, U.K.
  381.       Otto Spaniol, Aachen Tech. Univ., Germany
  382.       Hideyoshi Tominaga, Waseda Univ., Japan
  383.       Pramode Verma, AT&T, U.S.A.
  384.  
  385.         Members : Sunshin An, Korea Univ., Korea
  386.     Yanghee Choi, SNU, Korea
  387.     Jin Pyo Hong, ETRI/PEC, Korea
  388.     Byungchul Shin, KAIST, Korea
  389.     Yongjin Park, Hanyang Univ., Korea
  390.     Donggyoo Kim, Ajou Univ., Korea
  391.     Seungkyu Park, Ajou Univ., Korea
  392.     Dongho Lee, Kwangwoon Univ., Korea
  393.     Kwangsue Chung, Kwangwoon Univ., Korea
  394.     Daeyoung Kim, Cheoungnam National Univ., Korea
  395.     Ilyoung Chung, ETRI, Korea
  396.     Chimoon Han, ETRI, Korea
  397.     Woojik Chon, ETRI, Korea
  398.     Hoon Choi, ETRI, Korea
  399.     Jaiyong Lee, Yonsei Univ., Korea
  400.     Tadao Saito, Tokyo Univ., Japan
  401.                   Tahahiko Kamae, HP Lab., Japan
  402.     Reigo Yatsuboshi, Fujitsu Lab., Japan
  403.     Kinji Ono, NACSIS, Japan
  404.     Michel Diaz, LAAS-CNRS, France
  405.     Christophie Diot, INRIA, France
  406.     Jean-Yves Le Boudec, IBM, Zurich Lab., Swiss
  407.     Georgio Ventre, Univ. di Napoli, France
  408.     David Hutchison, Lanchaster Univ., U.K.
  409.     Augusto Casaca, INES,Portugal 
  410.     Martina Zitterbart, Univ. of Karlsruhe, Germany
  411.     Ulf Koerner, Lund Univ., Sweden
  412.     David J. Farber, Univ. of Pennsylvania, USA
  413.     Reg A. Kaenel, Marcicopa-County Comm. College, USA
  414.     Ira Cotton, USA
  415.     Martin E. Silveretoin, USA
  416.     Albert Kuendig, Swiss Federal Inst. of Tech., Swiss
  417.  
  418.  
  419. · 
  420. ------------------------------
  421.  
  422. From: Yves Blondeel <yves.blondeel@fundp.ac.be>
  423. Subject: Re: Emergency Numbers in Various Countries
  424. Date: 6 Dec 1994 19:48:18 GMT
  425. Organization: FUNDP, Namur, Belgium
  426.  
  427.  
  428. Kimmo.Ketolainen@utu.fi (Kimmo Ketolainen) wrote:
  429.  
  430. > Do you have any other to add, Pat? -- list of emergency numbers.
  431.  
  432. The European Union has adopted 112 as a single European emergency call
  433. number. This was done by Council Decision 91/396/EEC of 29 July 1991.
  434.  
  435. Article 1 of the Decision states that:
  436.  
  437. Member States shall ensure that the number 112 is introduced in public
  438. telephone networks as well as in future integrated services digital
  439. networks and public mobile services, as the single European emergency
  440. call number.
  441.  
  442. The single European emergency call number shall be introduced in
  443. parallel with any other national emergency call numbers, where this
  444. seems appropriate.
  445.  
  446. Article 2 of the Decision states that:
  447.  
  448. The single European emergency call number shall be introduced by
  449. 31 December 1992 at the latest, except... (exceptions to be justified)
  450.  ..
  451.  
  452. Note: if exceptions are used, the new date must be no later than
  453.       31 December 1996.
  454.  
  455.  
  456. Yves Blondeel
  457. yves.blondeel@fundp.ac.be
  458.  
  459. ------------------------------
  460.  
  461. From: fd@wwa.com (Glen L. Roberts)
  462. Subject: Re: WilTel Ignores *67 For Caller ID, Also Incorrect Billing
  463. Date: 6 Dec 1994 20:04:31 GMT
  464. Organization: WorldWide Access - Chicago Area Internet Services 312-
  465. 282-8605
  466.  
  467.  
  468. Glen L. Roberts (fd@wwa.com) wrote:
  469.  
  470. > CID Tech/INSG (dreuben@netcom.com) wrote:
  471.  
  472. >> I just noticed that WilTel has turned on Caller ID signaling from 
  473. CT
  474. >> to points outward, such as New York and New Jersey.
  475.  
  476. > You can always check by calling 10555-1-708-356-9646 ... also, 
  477. preceed
  478. > it with the *67 ... You will hear whatever Caller-ID Info AmeriTech
  479. > passes on.
  480.  
  481.  
  482. > [TELECOM Digest Editor's Note: I got some interesting results from
  483. > trying out the above number in different ways. When I simply dialed
  484. > it locally (I am in 708) as 356-9646 it responded with a message
  485. > giving me the (non-published) name and number on my phone. When I
  486.  
  487. Even though I log this information analyze what areas supply what
  488. information, it is not sold, or used for any marketing purposes (you
  489. gotta leave a message if you want any more information...). I am quite
  490. happy if people just use it to expirement with the phone system.
  491.  
  492. > dialed it with *67 first, then it responded by telling me I had
  493. > pressed that code to hade my name and number. In both instances
  494. > after a short blurb about Caller-ID and privacy, it then went on
  495. > to say if calling from a fax machine to press 3, otherwise to begin
  496. > speaking and leave a message. But ... I tried some other things as
  497. > well:  Dialing 10555-356-9646 (remember, I am in 708 so don't use
  498.  
  499. Interestingly, Wiltel doesn't pass caller-id OUT OF illinois. For
  500. example, when I called my Dad in Michigan, he doesn't get my number
  501. (Wiltel is my normal LD carrier). Yet, if an associate in CA who also
  502. uses Wiltel calls my dad in Michigan... caller-id is passed.
  503.  
  504. Wiltel in Michigan (313 and 616 but not 517) does passed Caller-ID 
  505. OUT.
  506.  
  507. > it in the dialing string) must have given his system some kind of
  508. > different reaction since instead of the opening spiel about Caller-
  509. ID,
  510. > and/or lack of same by dialing *67 it answered immediatly with the
  511. > message about 'if from a fax machine dial 3 ....', in other words
  512. > in the middle of the original message. I also tried dialing to it
  513. > via a WATS extender I am authorized to use in California. That is,
  514. > I dialed the 800 number for my contact in California then outdialed
  515. > back to 708-356-9646. That time Glen's machine answered the same
  516. > way, but cutting in at the middle of the message telling me to
  517. > 'dial 3 if calling from a fax machine ...'.   So apparently if the
  518. > Caller-ID he gets is 'outside area' he chooses not to give has
  519.  
  520. Some others have commented on that ... and soon, it will have a
  521. message for "out of area." I get no information about *67 if it is out
  522. of area.
  523.  
  524. When you outdialed back to 708-356-9646 did you do it through Wiltel
  525. (10555)?  If not, I doubt I'd get a number, as Wiltel seems to be the
  526. only carrier currently passing caller-ID. (incidentally, I have gotten
  527. names from 313, 216 and a couple other area codes).
  528.  
  529. > spiel at all ... and by using 10555 in front of the seven digit
  530. > number -- even though local to me -- apparently no ID of any kind
  531. > was passed as far as Glen. Then just on a lark I tried one final
  532. > combination, dialing *67-10555-356-9646. That also cut me into the
  533. > middle of his message (press 3 now). I am surprised he does not
  534. > have some sort of greeting for that condition (outside of area)
  535. > as well, since he provides for the other two conditions.   PAT] 
  536.  
  537. According to Chris Cappuccio, you can fake out the number it gets:
  538.  
  539. Call 1-800-288-2880
  540.  
  541. Enter 616-334-3257-94  (or any number of a COCOT phone that uses
  542. Wiltel/Encore)
  543.  
  544. Enter YOUR calling card number.
  545.  
  546. Enter (708) 356-9646 when it asks for a number to call.
  547.  
  548. You should hear 616-334-3257 (or the COCOT phone number), not the
  549. number you are calling from.
  550.  
  551.  
  552. Glen L. Roberts, Editor, Full Disclosure
  553. Host Full Disclosure Live (WWCR 5,065 khz - Sundays 7pm central)
  554. email fd@wwa.com for catalog on privacy & surveillance.
  555. Does 10555-1-708-356-9646 give you an "ANI" readback? With name?
  556. email for uuencoded .TIF of T-Shirt Honoring the FBI
  557. Remember, fd _IS FOR_ Full Disclosure!
  558.  
  559. ------------------------------
  560.  
  561. From: shawnlg@netcom.com (Shawn Gordhamer)
  562. Subject: Re: 911 From Unactivated Cell Phone?
  563. Organization: NETCOM On-line Communication Services (408 261-4700 
  564. guest)
  565. Date: Tue, 6 Dec 1994 19:26:53 GMT
  566.  
  567.  
  568. John Higdon <john@bovine.ati.com> writes:
  569.  
  570. > Not in California. Service providers and phone vendors are
  571. > specifically prohibited from in any way linking the sale of the 
  572. phone
  573. > to the activation of service. Although a number of dealers have 
  574. tried
  575. > some sleazy tricks to avoid selling phones without activation 
  576. ("sorry,
  577. > I just looked and we are out of stock -- someone must not have taken
  578. > the last one out of the computer..."), I have inside information 
  579. that
  580. > even as we speak there are some undercover efforts to bring the big
  581. > foot down on them.
  582.  
  583. So what great "wrong" was the CA politicians trying to rectify by
  584. passing this law?  It seems like this is hurting, rather than helping
  585. consumers.  I'm glad I'm not in CA (for a lot of reasons)!
  586.  
  587.  
  588. Shawn Gordhamer    shawnlg@netcom.com
  589.  
  590. ------------------------------
  591.  
  592. End of TELECOM Digest V14 #441
  593. ******************************
  594.  
  595.                               
  596.  
  597.  
  598.  
  599.  
  600.